This section contains a discussion of background. It summarizes telecommunications carrier network architectures that currently exist as legacy or that are currently under development. It also includes discussion of insights and observations made by the inventor about the prior art systems that are helpful to understanding the subsequently described invention but that were not necessarily appreciated by persons skilled in the art or disclosed in the prior art. Thus, the inclusion of these insights and observations in this background section should not be interpreted as an indication that such insights and observations were part of the prior art. After the background discussion, a new Edge Switched Network (ESN) architecture is introduced and it is described and compared to leading “Next Generation Network” alternatives. A Distributed Edge Switch (DES) makes possible the implementation of an ESN. In the OVERVIEW section that is found in the Detailed Description section, the design, operation and management of the DES are described within the architectural context provided by the ESN.
Next Generation Networking Approaches
In recent years, attempts to transform the legacy Public Switched Telephone Network (PSTN) to exploit the potential of the Internet has led to approaches that are loosely referred to as the Next Generation Network (NGN). It was believed that such approaches would lead to converged networks. Converged networks promise substantial cost savings and new service opportunities for telecommunications carriers (a.k.a. “carriers,” or “network service providers”). As a means to realize new data services, carriers have deployed overlay networks, which require overlay of new infrastructure onto existing legacy voice networks. In contrast, the converged approach of the NGN seeks to eliminate the need to have separate networks for different media. It exploits the principles of “openness” and leverages the standard protocols of IP networks to carry not only data but also other media such as voice and video.
The PSTN and AIN Principles
The NGN grew out of the PSTN, thus to understand its origins one must understand present day Advanced Intelligent Network (AIN) employed by PSTN carriers to provide advanced telephony services. The AIN was proposed as the solution to the carriers' needs to produce applications rapidly and independently of switch development efforts. Prior approaches had bundled services within switches, giving rise to long development times and inflexible service deployment. Service development and deployment was intimately tied to switch evolution and switch development cycles.
AIN proposed de-coupling service development and service logic from switches by building appropriate trigger points within the switch. Upon encountering a trigger detection point while processing a call, the switch, called the Service Switching Point (SSP), would trigger and send a query to a Service Control Point (SCP). FIG. 1 illustrates the elements of AIN. The SSP performs a query directed to an SCP. The SCP executes service logic that yields a result and that result is returned to the SSP that initiated the query. The SSP then continues with call processing.
As an example, when a subscriber dials an 800 number, an SSP detects that the call requires AIN service logic processing. The SSP directs a query to an SCP which in turn executes service logic that returns a valid dialing number to the SSP. The SSP then asks the Signaling System #7 (SS#7) network to set-up a call to that telephone number. SS#7 sets up signaling and bearer paths necessary to support a call to that dialing number. The CENTRAL OFFICE SWITCH serving the called party applies a ringing tone to the called party's telephone. Once the called party answers, the call is established and both the parties can now have a telephone conversation.
FIG. 1 depicts the structure of the PSTN, including its support for AIN. The CENTRAL OFFICE SWITCH is decomposed into four distinct modules:    CALL PROCESSING    LINE    SIGNALING    TRUNK
The LINE module functions include detecting on-hook/off-hook, applying dial tone and ringing tone, collecting dialed digits, and communicating internally with the call-processing module. The CALL PROCESSING module analyzes the digits collected by the LINE module, and asks the SIGNALING module to perform appropriate actions. The SIGNALING module interfaces with the SS#7 TRANSPORT NETWORK for the purpose of setting up a bearer channel between the calling and the called CENTRAL OFFICE SWITCHES. The TRUNK module transforms analog voice to a Time Division Multiplexed (TDM) format for transmission over PSTN trunks. The TRUNK module of the CENTRAL OFFICE SWITCH serving the called party converts the TDM trunk format back to analog for transmission over the local loop.
The Next Generation Networking Model
FIG. 2 illustrates the NGN approach. The NGN exhibits several similarities to the legacy PSTN. If one were to split apart the four modules that comprise the CENTRAL OFFICE SWITCH (see FIG. 1) into separate and distinct computing elements, the following components of a NGN network result:    MEDIA GATEWAY CONTROLLER    RESIDENTIAL GATEWAY    TRUNK GATEWAY    SIGNALING GATEWAY
To compare the functions of these elements to analogous functions in the CENTRAL OFFICE SWITCH, the MEDIA GATEWAY CONTROLLER (A.K.A. “softswitch,” or “call agent) performs the functions of the CALL PROCESSING module, the RESIDENTIAL GATEWAY (A.K.A. “customer gateway”) performs the functions of the LINE module and the TRUNK GATEWAY replaces the TRUNK module. Insofar as the RESIDENTIAL GATEWAY and TRUNK GATEWAY are both responsible for converting media provided in one type of network to the format required in another type of network, they are referred to generically as MEDIA GATEWAYS. With respect to support for network signaling functions, the SIGNALING GATEWAY in the NGN replaces the SIGNALING module in the CENTRAL OFFICE SWITCH. The similarities between the PSTN and NGN end here.
FIG. 2 shows a PACKET TRANSPORT NETWORK based on IP in OSI Layer 3 (the network layer) transported over ATM in OSI Layer 2 (the datalink layer). It interconnects all four NGN network elements. What were once major modules within a CENTRAL OFFICE SWITCH are now distributed network elements interconnected through a PACKET TRANSPORT NETWORK. The distributed nature of network elements in an NGN brings out one of the most striking differences between the PSTN and the NGN approaches. The theoretical advantages to be gained from this distribution include the following:
The MEDIA GATEWAY CONTROLLER may be implemented on a reliable, high-performance, fault-tolerant server that is IP-based and uses standard protocols to communicate with the gateways. Services can be implemented on separate platforms using open application programming interfaces (API), which should in theory lead to rapid development and deployment of services.
The MEDIA GATEWAYS can send media to each other over an IP-based PACKET TRANSPORT NETWORK using a protocol called Real Time Transport Protocol (RTP). The RTP protocol can be used to transmit not only voice but also data and video. The same IP transport and protocol can be used to carry multiple media types concurrently, a task that is difficult to accomplish with the circuit-switched PSTN network.
Unlike with the PSTN, where the signaling network is separate from the voice network, NGN utilizes the same PACKET TRANSPORT NETWORK to carry both signaling and media traffic.
Whereas communication between the four major modules is internal to the CENTRAL OFFICE SWITCH in the PSTN, the NGN uses a gateway control protocol for communication between the MEDIA GATEWAY CONTROLLER and the MEDIA GATEWAYS.
The most widely studied gateway control protocol is Media Gateway Control Protocol (MGCP) described by IETF RFC 3015 on Megaco Protocol Version 1.0. RFC 3015 is a common text with ITU-T Recommendation H.248, the most recent draft of which was developed as a close cooperation between the IETF Media Gateway Control Working Group (A.K.A. “MEGACO Working Group”) and ITU-T Study Group 16.
The precursor to MGCP was the Simple Gateway Control Protocol (SGCP) developed by Telcordia. At about the same time Telcordia was implementing SGCP, a company called Level 3 had developed a similar protocol called IP Device Control (IPDC). Rather than have two similar protocols develop and compete over time, Telcordia and Level 3 merged them into MGCP. MGCP was tailored to address a PSTN telephone and was not designed to handle data or multimedia. ITU-T Study Group 16 extended MGCP to support ISDN and multimedia, which led to Recommendation H.248. This body of work is today referred using the moniker MEGACO/H.248; it details a NGN reference architecture that provides an operational context for the description of the MGCP itself.
FIG. 2 depicts an NGN that is architecturally compatible with MEGACO/H.248. The following workflow sequence illustrates a typical call set-up procedure for the NGN depicted in FIG. 2:
(1) A telephone goes off-hook. The RESIDENTIAL GATEWAY serving the telephone detects the off-hook event, applies dial tone, collects the dialed digits, and notifies the MEDIA GATEWAY CONTROLLER using MEGACO; The RESIDENTIAL GATEWAY also informs the MEDIA GATEWAY CONTROLLER that it is prepared to receive an RTP media stream at a certain port address, and further indicates the audio coding format it is able to support.
(2) The MEDIA GATEWAY CONTROLLER processes the digits and then must determine whether the called party telephone is connected to another RESIDENTIAL GATEWAY within the NGN or connected to a CENTRAL OFFICE SWITCH in the PSTN.
(3) Assuming the called party is connected to another RESIDENTIAL GATEWAY within the NGN, the MEDIA GATEWAY CONTROLLER queries the RESIDENTIAL GATEWAY serving the called party for an RTP port (and the audio coding format) at which it would prefer to receive an RTP stream from the calling party RESIDENTIAL GATEWAY.
(4) The called party RESIDENTIAL GATEWAY responds with the port at which it can receive an RTP audio stream from the calling party and the audio coding format it is able to support.
(5) The called party RESIDENTIAL GATEWAY applies a ringing tone to the called party's telephone.
(6) The MEDIA GATEWAY CONTROLLER informs the calling RESIDENTIAL GATEWAY of the audio coding format supported by the called RESIDENTIAL GATEWAY and the port at which it is expecting to receive an RTP stream.
(7) Following more exchanges of information, both the calling and called party RESIDENTIAL GATEWAYS know the port addresses and supported audio coding formats necessary for them to send and receive RTP streams (containing encoded audio) to/from each other.
(8) Once the called party answers the telephone, two-way communication using RTP streams is established.
Implications of NGN Deployment
There are several significant implications that result from delivering network services to subscribers through an NGN rather than the PSTN. Several of them are summarized in the points below:
Unlike the PSTN, which has a signaling network that is separate from the TDM network for establishing bearer paths, the NGN network carries both signaling and media streams over the same IP network, thereby achieving a certain measure of convergence.
Whereas the PSTN requires separate overlay networks and protocols for other media beyond voice, the NGN utilizes the same IP network and protocols for all media communications (i.e. voice, data, video).
While the PSTN carries voice media over dedicated circuit switched connections, NGN carries media streams in RTP packets that are treated in the same manner as any other IP packets, using the “best effort” paradigm the Internet employs for routing packets. This means that packets can encounter delays; they can be dropped due to congestion control mechanisms that throttle packets at the source or at the ingress to the network. Hence, the bare public Internet does not offer quality of service. Consequently, an NGN implementation requires the creation of a special-purpose IP network to support network quality of service (QoS). In contrast, the PSTN is capable of guaranteeing QoS service for point-to-point connections transporting voice or data.
The NGN interworks with the PSTN via TRUNK GATEWAYS and SIGNALING GATEWAYS. Thus, while the end-to-end connection between two NGN subscribers would occur entirely within the PACKET TRANSPORT NETWORK, the end-to-end connection between and NGN subscriber and a PSTN subscriber would occur in both the NGN and the PSTN, using a TRUNK GATEWAY and a SIGNALING GATEWAY to carry bearer channel content and network signaling information, respectively, between the two subscribers participating in the call.
Third-party applications can be offered via an open applications programming interface (API) offered by the MEDIA GATEWAY CONTROLLER. Some standards for Open APIs include PARLAY, JAIN, XML, or SOAP. It is beyond the scope of this discussion to provide definitions for these APIs or to elaborate on them beyond presenting their monikers. Let it simply be said that the thrust of these APIs was originally an effort to make AIN infrastructure in the PSTN accessible to third-party application providers so that they could offer new and innovative network services. With the advent of the NGN, it was envisioned that the same set of APIs would be suitable to provide third-party NGN applications with the ability to access similar features by interfacing with the MEDIA GATEWAY CONTROLLER.
The NGN makes it possible for a carrier to provide plain old telephone service (POTS) over a PACKET TRANSPORT NETWORK by using a MEDIA GATEWAY CONTROLLER and a RESIDENTIAL GATEWAY rather than a CENTRAL OFFICE SWITCH. As already explained, the RESIDENTIAL GATEWAY takes on the role of the LINE module of the CENTRAL OFFICE SWITCH; therefore, there are no NGN requirements to change the telephone itself.
A Victim of Failed Economics
Though the NGN is today restricted in its applicability to voice communications, it was originally the hope of both carriers and vendors that voice-over-IP (VoIP) would serve to bootstrap the NGN and spawn off a new era of converged networks that would cater to voice, video and data communications. Convergence promised to transform the PSTN into a general purpose “multi-service network” capable of simultaneously delivering voice, video and data services through a common PACKET TRANSPORT NETWORK that supports QoS. Thus far this expectation has not materialized due to the carriers' reluctance to widely deploy a network based on the NGN architecture. At the current time, many carriers perceive the NGN architecture unsuitable to meet their forward-looking objectives to decrease network operating costs while at the same time increase network service revenues. Ultimately the NGN became a victim of failed economics that resulted from its inordinate complexity and insufficient support for new services.
Complexity Confounds NGN Deployment
The inordinate complexity of the NGN is to a large extent due to overreliance on centralized control elements for network service delivery. While its many network elements may be physically distributed, the NGN architecture's logical centralization mimics the functionally of the “mainframe-oriented” PSTN. The NGN architecture has more recently been altered from its original design to model the Internet, relying upon a “horizontal integration” of specialized, cooperating network elements. Many of these network elements are not shown in FIG. 2, but are necessary for NGN implementation (e.g. feature servers, media servers, integrated access device controllers, policy servers, domain naming servers, SIP proxy servers, TRIP servers, subscriber directory servers). Very much unlike the internet, virtually all NGN network elements require some degree of centralized control by, or interaction with, the MEDIA GATEWAY CONTROLLER according to specialized protocols. All of these protocols communicate through (i.e. generate traffic on) the carrier's PACKET TRANSPORT NETWORK.
To support its centralized service delivery model, the “vertically integrated” PSTN was based on a hardware scaling model in which the majority of software processes communicated directly with each other inside purpose-built hardware computing modules. These computing modules physically plugged into each other to create large, distributed mainframe computers such as the CENTRAL OFFICE SWITCH. The more horizontally integrated NGN is based on a software scaling model that for all intents and purposes remains as operationally centralized as the PSTN, if not more so in some instances where control over a very large number of subscribers (potentially millions) may be aggregated into a regional office. Adherents of the NGN architecture maintain that such a high degree of centralization offers cost benefits; however the cost benefits of centralization are to a large measure offset by fault vulnerability and the costs associated with ensuring system redundancy. Generally speaking, if something in a network does anything for thousands of subscribers at the same time, not only does the carrier need two of them, but also the ability to automatically fail over from one to the other without dramatically interrupting service delivery. Implementing this level of functionality for centralized components is challenging and often prohibitively expensive.
As depicted in FIG. 2, the physically distributed, highly-decomposed NGN architecture relies upon a an “orchestra”0 of interdependent software services running on distributed network elements; these software services, each according to its unique role, communicate in one-to-one, many-to-one, or one-to-many relationships with other interdependent software services through the PACKET TRANSPORT NETWORK, each using specialized protocols.
Due to physical limitations on how many MEDIA GATEWAYS can be controlled by a single MEDIA GATEWAY CONTROLLER, the NGN must be partitioned into control zones. Local device-level signaling performed by the MEDIA GATEWAY CONTROLLER within its control zone must be somehow synchronized with end-to-end network signaling that would be necessary for a call to span more than a single zone. The result is a two-tiered signaling architecture—a concession to the inelegant NGN scaling model and its inherent requirement for network partitioning. Network signaling protocols such as Session Initiation Protocol (SIP) are used between control zones for end-to-end network signaling, whereas MEGACO is used closer to the endpoint for local MEDIA GATEWAY control.
Among other things, the two-tiered signaling model complicates the integration of APPLICATION SERVERS (and potentially PBXs) that typically require more signaling information than can be conveyed by MEGACO (e.g. calling and called party dialing numbers). As a result, network signaling using SIP must be extended directly to the APPLICATION SERVER as if it were another MEDIA GATEWAY CONTROLLER i.e. another “control zone.” Thus, for the NGN to enable network-based enhanced services such as voice mail or group conferencing, it must interface APPLICATION SERVERS using a different method than the way it interfaces telephones. From an operational perspective, the two-tiered signaling model means that the MEDIA GATEWAY CONTROLLER becomes a lynch pin, and must now actively mediate all telephone access to the APPLICATION SERVERS.
In the NGN, subscriber telephones are connected through RESIDENTIAL GATEWAYS and controlled by the MEDIA GATEWAY CONTROLLER using MEGACO. This complexity has further implications in terms of complicating overall network design, particularly with respect to the scaling of participating network elements. Thus, as a consequence of its inordinate complexity, the NGN architecture brings with it a number of very significant implementation considerations that may be summarized as follows:
Potential poor performance resulting from the high processing overhead: network functionality is highly decomposed into distributed network elements that must communicate through the network itself using various protocols;
Numerous indeterminate scaling relationships that introduce a proportionally larger number of potential bottlenecks;
Troubleshooting procedures that must isolate and resolve problems that appear to reside in more than one place do to protocol incompatibilities;
Software integration requirements that are difficult for most carriers to support.
It is the conclusion of this analysis that the NGN architecture as represented in FIG. 2 has too many moving parts to operate efficiently. Attempts to remedy these limitations ultimately translate into implementation cost for the carrier attempting to deploy an NGN.
Insufficient Support For New Services Confounds NGN Deployment
The NGN architecture suffers from insufficient support for new services. It largely replicates the telephone-oriented feature set of today's PSTN. Due to the centralized control model of the NGN, support for new network services is dependent upon the ability of the MEDIA GATEWAY CONTROLLER and APPLICATION SERVERS to provide the features that comprise a network service. Much like with the PSTN, feature delivery by a centralized controlling entity is limited by the carrier's ability (and willingness) to modify the controlling entity to provide new services. Notwithstanding the NGN vision of third-party applications and new services supported through MEDIA GATEWAY CONTROLLER APIs, as a practical matter it is a tenuous proposition to modify access to it, or add to its service load once it has been optimized to deliver a particular portfolio of services.
Beyond risks related to destabilizing the core of the network by providing API access to the MEDIA GATEWAY CONTROLLER, the generic concept of using APIs to integrate application services came into question some time after the inception of the NGN and its API-based strategy. In actual practice—“actual practice” being a function of industry consensus derived from years of internet experience—third-party applications offered through the NGN are probably better integrated using standard IP-based IETF protocols such as SIP and Hypertext Transfer Protocol. APPLICATION SERVER integration into the PACKET TRANSPORT NETWORK using internet-style protocols (based on message passing) has proven far more flexible and cost-effective than integrations based on APIs. APIs tend to be highly vendor-specific, programming language-specific, and, since they are based fundamentally on function calls rather than message sets, tend to be less tolerant of partial implementation.
Notwithstanding the foregoing, it should be kept in mind that network signaling protocols like SIP are not compatible with the device-oriented MEGACO protocol used to control telephones connected to RESIDENTIAL GATEWAYS. Thus, as pointed out earlier in the discussion, the two-tiered signaling model of the NGN puts the MEDIA GATEWAY CONTROLLER into a mediation role, performing an imperfect translation between its use of MEGACO to control service delivery to telephones and its use of SIP as the means to access application services.
Interactive calling services were originally envisioned that would provide the NGN subscriber with the ability to select or customize call processing logic, perhaps even to enable interoperability between network features and application programs running on the subscriber's personal computer (e.g. active browser sessions, instant messaging clients) or to access subscriber-specific data objects (e.g. contact lists, call logs, content subscriptions). Implementation of these types of interactive calling services using only AIN-style APIs was eventually perceived as largely impractical in the NGN because the MEDIA GATEWAY CONTROLLER (supporting the APIs) would be required to access, manage, and execute unique, complex service logic for very large number of subscribers at the same time. The following points illustrate other significant limitations of the NGN with respect to supporting new services:
In the NGN, the MEDIA GATEWAY CONTROLLER delivers telephone features by remotely controlling the RESIDENTIAL GATEWAY. It can only deliver features through a RESIDENTIAL GATEWAY whose feature set it fully understands according to the MEGAGO standard. This factor imposes substantial constraints on the variety of network services the NGN can deliver because it is impractical or unfeasible to control an endpoint feature set that extends beyond that anticipated by MEGACO.
Calling services that perform call control operations require a full knowledge of subscriber Class of Service parameters and service delivery preferences. This information governs not only the subscriber's ability to invoke the calling service in the first place, but the unique behavior of the service when invoked by that particular subscriber. Most of the information that interactive calling services (e.g. call log functions, programmable call-blocking and call-forwarding) require is buried somewhere deep inside the NGN infrastructure in much the same way that it was buried inside the CENTRAL OFFICE SWITCH in the PSTN. This factor imposes substantial constraints on the variety of network services the NGN can deliver because call log entries and related subscriber-specific network usage data are largely unavailable for real-time access by third-party applications.
RESIDENTIAL GATEWAYS are unintelligent in the sense that they require the MEDIA GATEWAY CONTROLLER to mediate all network signaling functions on their behalf. They cannot determine the broader network signaling context of the calling operations in which they participate. They are incapable of independently executing service logic that involves network signaling operations (e.g call redirection, multipoint call control, call supervision, multiple line appearances, etc.) without centralized participation by the MEDIA GATEWAY CONTROLLER. These factors impose substantial constraints on the variety of network services the NGN can deliver because each new service must be tightly integrated with the MEDIA GATEWAY CONTROLLER in order to perform call control operations.
To work around these constraints, recent approaches to offering new services in the NGN have put an application between the RESIDENTIAL GATEWAY and the MEDIA GATEWAY CONTROLLER. The application is responsible for controlling the subscriber's telephones, giving them access to various new features. These approaches support: (a) a variety of telephone types not supported by standard MEGACO; (b) better access to call log records and related subscriber-specific network usage data; and (c) the ability to execute user-configurable service logic not supported by the MEDIA GATEWAY CONTROLLER.
As an example of this approach, companies such as Cisco, Broadsoft, LongBoard, and Sylantro have built application systems that provide optimized combinations of business telephone services that include PBX and Centrex features. While some of these solutions are designed for enterprise deployment, those intended for carrier deployment are often referred to using the moniker “IP Centrex.” IP Centrex solutions provide calling services and telephone features using various brands of office telephones and web browser-based graphical user interfaces. Generically, IP Centrex solutions equate to a network-based software PBX application that replaces much of the functionality of the MEDIATE GATEWAY CONTROLLER.
IP Centrex solutions are often referred to in the industry as “point solutions.” Point solutions enable the carrier to provide a very particular set of new services for isolated populations of subscribers. They are a work-around bourne out of necessity and introduce additional “non-standard” intermediary network elements into the NGN. Adding new network elements of this type brings with it significant scaling implications associated with carrier deployment of a service that cannot scale as the network itself scales. Point solutions are operationally unfeasible for carriers serving tens of millions of subscribers because the feature set of the point solution cannot be managed as a standard network feature set that may be enabled or disabled for any subscriber at will. If such a service became popular, the carrier would have to replicate many instances of the system—potentially thousands of them—each to serve a certain critical mass of subscribers, and then to manage these systems as independent islands of service delivery capability.
As summarized below, point solutions bring with them their own unique set of carrier deployment challenges and at the same time do not resolve the general limitations of the NGN with respect to supporting new services:
Point solutions do not in a general sense enable the NGN to control a telephone feature set (or other endpoint device feature set) that extends beyond that anticipated by MEGACO, but instead supports selected vendor telephones in a way that suits their own specific purposes.
Point solutions do not in a general sense make call log records and related subscriber-specific network usage data available for real-time access by a third-party applications, but instead simply store it internally for their own use.
Point solutions do not in a general sense make it possible for third-party applications to perform call control operations, but instead implement call control operations for their own specific purposes.
NGN Support For Multi-Service Delivery
The NGN architecture leaves to future consideration features sets that extend beyond traditional PSTN voice services. It assumes central office (or equivalent) deployment for most network elements and that the RESIDENTIAL GATEWAY is providing telephone service over a general-purpose PACKET TRANSPORT NETWORK that supports QoS. Video and data services are not addressed directly by the NGN, and it is assumed that other network elements and related infrastructure components will provide these services independently.
The above assumptions do not anticipate that the subscriber purchasing voice services is also likely to purchase data and video services from the same carrier. When the carrier's primary connection to the subscriber premise is through a broadband access network, it quickly become impractical to install a separate physical connection or independent solution for each type of media service offered to that subscriber. Much of the motivation behind the transition to a converged network is based on the notion that multiple services—voice, video, and data services—can be offered to a network subscriber through a single IP data path to the premise. The converged vision extends to enabling carriers to combine several media types into a comprehensive network services offering.
This type of multi-service delivery requires QoS arbitration at the subscriber premise so as to ensure QoS for all voice, video, and data terminal devices (i.e. telephones, televisions, PCs) installed there; all of these terminal devices may be operating at the same time sharing the same IP data path. Many potential new services anticipate providing value to subscribers because of their ability to support multiple media types at the same time, potentially integrating two services that support different media types in a way that makes each more useful. In addition, voice, video and data terminal devices installed at the subscriber premise often support different control interfaces that must be normalized to network signaling and device control conventions that would enable them to interact with network-based APPLICATION SERVERS in a consistent fashion.
Equipment vendors have responded to requirements to enable NGN multi-service delivery through a single IP data path to the subscriber premise by creating an integrated access device (IAD). The IAD began life as specialized version of a RESIDENTIAL GATEWAY, designed as a means to enable subscribers to connect voice and data terminals at the premise in such fashion as they may share a common IP data path to the carrier's PACKET TRANSPORT NETWORK. The IAD marketplace today offers the carriers a bewildering assortment of devices, targeting optimal combinations of cost effectiveness and/or feature richness.
Some IADs support voice-over-IP and QoS arbitration features whereas others attempt to obviate total reliance on remote IAD control by a MEDIA GATEWAY CONTROLLER (using MEGAGO) by implementing selected POTS telephone features and SIP network signaling within the IAD. Some IADs used by the cable industry do not support VoIP in the NGN sense of it, but instead provide for “voice-over-broadband.” The term voice-over-broadband refers to a family of proprietary access network designs, the most common of which is that used by cable companies that transport voice, as well as data and video, on distinct broadband channels created through frequency division multiplexing (FDM). In this type of voice-over-broadband network, voice and data flows are split at the central office (or central office equivalent), with the voice path connecting to a CENTRAL OFFICE SWITCH (usually through a GR 303 packet interface). IADs of this type are excepted from this discussion because they do not support the converged “end-to-end IP” vision of the NGN and are fundamentally incompatible with it.
NGN voice services offered through an IAD using VoIP are virtually identical to voice services offered directly through a POTS line connected to a CENTRAL OFFICE SWITCH. Typically, the IAD is used to connect telephones and computers to a broadband data service provided to the premise. Through the gateway facilities of the IAD, voice and data are transported as distinct packet flows over a common IP data path that is contiguous (from an IP connectivity standpoint) with the PACKET TRANSPORT NETWORK. In the NGN, the feature set of the CENTRAL OFFICE SWITCH is emulated by the MEDIA GATEWAY CONTROLLER in concert with a number of other network elements such as a “feature server.” Conceptually, in the NGN the IAD functions exactly as any other RESIDENTIAL GATEWAY.
Unable to deliver traditional PSTN network services independently, and devoid of the ability to enable compelling new service capabilities, the value proposition of the IAD lies in its ability to enable the subscriber to use one physical line (e.g. DSL line, cable, T1) for both voice and data at the same time. In summary, the cost of the IAD must be compared to the cost of simply installing separate voice and data lines to the premise.
After substantial field experience, technical staff at two major United States Local Exchange Carriers recently concluded that the cost for them to deploy network services using an IAD is greater than or equal to the cost to deploy separate voice and data lines to the premise, except in rare cases where it would be exceptionally expensive to bring in an additional line. Despite wide availability several for years, the limited deployment of IADs further suggests that the NGN has been a victim of failed economics. From a pure technical perspective, an IAD may be an appropriate “edge device” form-factor to address MEGACO requirements for multi-service delivery to the subscriber premise. This observation does not remedy the underlying problem that its cost to deploy is perceived as more than can be justified by the modest functionality it enables.